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INTRODUCTION 


Multics  is  a state-of-the-art  operating  system  currently  running 
on  several  Honeywell  Information  Systems  computers  in  the  6000 
line.  It  is  a very  powerful  time-sharing  system  which  lends 
itself  to  a great  deal  of  hands-off  versatility.  This  report 
discusses  the  procedure  used  to  run  a series  of  machine-dedicated 
performance  evaluation  tests  without  any  machine  operator 
intervention,  either  before  or  after  the  tests,  and  with  minimum 
disruption  to  normal  timesharing  service.  The  procedure 
involves,  among  other  things,  setting  up  a control  program  to 
execute  at  some  optimum  time  in  the  future,  whereupon  Multics  is 
automatically  induced  to  remove  itself  from  its  normal  user 
support  status,  log  in  a predetermined  set  of  artificial  users 
for  the  duration  of  the  test,  and,  following  this,  restore  itself 
to  its  normal  user  (timesharing)  status.  The  value  of  this 
procedure  may  be  generalized  to  any  instance  where  dedicated, 
hands-off  service  of  some  kind  is  desirable. 


MULTICS  EXEC  COM  FACILITY 


An  exec_com  is  a macro  capability  in  Multics  which  allows  a user 
to  execute  an  ascii  file  containing  one  or  more  interactive 
command  lines,  i.e.,  those  lines  which  are  normally  typed  at  a 
terminal  when  a user  is  in  the  timesharing  or  interactive  mode. 
A number  of  bells  and  whistles  are  available  within  the  exec_com 
facility  which  serve  to  make  it  quite  flexible  and  powerful, 
e.g.,  if-then-else  conditionals,  go-to's,  interrogation  of  users, 
etc.  These  are  called  control  lines.  In  addition,  when  an 
exec_com  is  called  into  execution,  arguments  may  be  passed  to  it 
as  part  of  the  calling  sequence,  and  these  arguments  can  be 
manipulated  within  the  exec_com. 

A user  may  execute  an  exec_com  at  any  time  by  typing  the  command 
line  at  his  terminal  which  calls  it  into  action.  It  is  also 
possible  to  call  an  exec_com  within  an  exec_com  (and  recursive 
calls  are  supported) . 


THE  MULTICS  ABSENTEE  FACILITY 


A user  may  choose  to  execute  an  exec_com  in  absentia.  When 
executed  in  this  way,  it  is  called  an  "absentee  job".  The 
"enter_absentee_request"  command,  or  "ear"  for  short,  is  the 
vehicle  for  doing  this. 

When  a user  submits  an  absentee  request  via  "ear",  Multics 
responds  in  one  of  two  ways,  depending  on  whether  or  not  he  wants 
to  defer  execution  of  the  exec_com  to  some  later  time.  If  a user 
does  not  request  deferral  of  execution,  and  Multics  currently  has 
no  restrictions  (see  below)  on  queueing  or  honoring  such 
requests,  the  absentee  job  will  immediately  log  in  (with  the 
submitting  user's  ID)  and  execute.  This  will  be  followed  by  a 
logout  upon  completion  of  the  job.  If,  on  the  other  hand,  the 
user  requests  execution  deferral,  Multics  will  delay  execution  of 
the  job  until  arrival  of  the  deferral  time  specified  by  him  in 
his  "ear"  command.  When  this  time  finally  arrives,  Multics 
immediately  executes  the  job  as  above,  but  once  again,  only  if 
there  are  no  restrictions  on  queueing  or  honoring  the  request. 
If,  for  some  reason,  Multics  cannot  honor  the  request  when  the 
deferral  time  arrives,  the  job  will  remain  in  queue  until  such 
time  as  all  restrictions  are  removed.  It  will  then  be  executed. 

The  restrictions  being  referred  to  above  are  as  follows: 

(a)  A user  must  have  appropriate  permission  in  order  to  submit 
an  absentee  request.  If  adequate  permission  does  exist,  the 
request  is  entered  into  one  of  three  priority  queues,  the 
choice  of  which  is  predetermined  by  the  user.  If  sufficient 
permission  does  not  exist,  the  job  will  never  get  to  the  point 
of  being  queued. 

(b)  Since  absentee  jobs  in  execution  contend  with  interactive 
users  for  computer  resources,  administrators  will  often  limit 
the  number  of  absentee  jobs  allowed  to  be  in  execution  at  any 
one  time.  Hence,  the  queue  effect  comes  into  play.  Another 
point  of  interest  is  that  a user  may  submit  as  many  absentee 
jobs  as  he  chooses,  and  the  only  thing  limiting  him  from 
having  them  all  logged  in  and  executing  at  the  same  time 
(other  than  his  deferring  execution)  are  administrative  limits 
placed  upon  the  absentee  facility. 

(c)  An  administrator  may  choose  to  restrict  which  of  the  three 
absentee  priority  queues  are  to  be  allowed  service  at  any 
particular  time.  If,  for  example,  only  queue  1,  the  highest 
priority  queue,  is  allowed  service  (queues  2 and  3 being 
restricted)  , then  a user  who  has  no  permission  to  enter  jobs 
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into  queue  1 is  effectively  prevented  from  executing  any 
absentee  jobs  during  the  restriction  period,  while  another 
user  who  has  permission  to  enter  jobs  into  queue  1 has  free 
reign  up  to  the  limits  imposed  by  (b) . 

The  absentee  user  facility  in  Multics  is  the  backbone  of  the 
capability  described  in  this  report.  Therefore,  for  emphasis,  a 
summary  and  enlargement  of  the  absentee  facility  characteristics 
(most  of  which  have  already  been  discussed)  is  now  provided: 

1)  An  "absentee"  job  is  analogous  to  "batch"  jobs  in 
conventional  operating  systems.  However,  instead  of  such  jobs 
being  executed  under  the  control  of  a computer  operator,  an 
absentee  job  will  either  execute  almost  immediately  (upon 
scheduling) , or  will  be  delayed  to  run  no  earlier  than  some 
predetermined  time  in  the  future,  all  at  the  discretion  of  the 
user  who  sets  up  the  conditions  for  running  such  a job  (but 
see  #3) . 

2)  An  absentee  job  is  scheduled  for  running  when  a user 
places  it  into  one  of  several  priority  queues  via  the 
"enter_absentee_request"  command  (or  "ear"  for  short) . 

3)  An  absentee  job  is  actually  viewed  by  Multics  as  an 
independent  user  and,  under  the  control  of  the  Multics 
absentee  user  facility,  logs  into  and  out  of  the  System  in 
much  the  same  way  as  a normal  user,  and  with  the  ID  of  the 
user  who  submits  the  job.  A user  has  the  power  to  create  any 
number  of  absentee  jobs,  but  Multics  contains  the  necesrary 
administrative  handles  to  restrict  the  number  of  absentee  jobs 
allowed  to  be  executed  in  the  System  at  any  one  time,  and  to 
restrict  priority  queues  in  which  these  jobs  may  be  scheduled 
for  execution. 

4)  An  absentee  job  has  the  same  power  to  perform  functions  in 
Multics  as  the  user  who  enters  the  request  for  an  absentee  job 
to  run.  This  occurs  because  an  absentee  job  is  nothing  more 
than  a stack  of  interactive  user  command  lines  interspersed 
with  appropriate  control  lines.  These  command  and  control 
lines  comprise  what  is  called  the  absentee  exec_com  or  control 
file,  more  commonly  referred  to  as  the  "absin"  file,  which  is 
simply  an  ascii  file  residing  in  a Multics  user's  workspace. 

5)  When  an  absentee  request  is  entered  by  a user,  among  the 
options  which  he  has  available  to  him  are  the  following: 

a)  Specification  of  the  output  file  (commonly  referred  to 
as  the  "absout"  file)  to  which  all  output  from  the  absentee 
job  will  be  directed.  This  output  is  equivalent  to  that 
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which  a normal  user  receives  at  his  terminal  upon  executing 
various  command  lines.  If  an  output  file  is  not  specified, 
a default  file  is  assigned  by  Multics. 

b)  Specification  that  the  job  is  to  be  restarted  in  the 
event  that  it  is  interrupted  by  the  system.  This  is  a 
complete  restart. 

c)  Specification  that  a CPU  time  limit  is  to  be  placed  on 
the  job. 

d)  Specification  that  the  job  is  to  be  entered  into  a 
specific  priority  queue,  if  the  user  has  access  to  that 
queue,  the  job  will  be  scheduled  for  execution.  Queue  3 is 
the  default  queue,  as  opposed  to  queues  1 and  2 which  are 
of  higher  priority  as  far  as  order  of  execution  of  jobs  is 
concerned . 

e)  Specification  that  the  job  is  not  to  log  in  for 
execution  any  earlier  than  a specified  time  in  the  future. 
If  a deferred  time  is  not  specified,  the  job  will  be 
scheduled  ana  executed  as  soon  as  Multics  can  honor  the 
request . 

f)  Specification  that  specific  arguments  are  to  be  passed 
to  the  absentee  job  at  the  beginning  of  execution.  This  is 
similar  to  passing  arguments  to  subroutines,  and  any  such 
arguments  are  included  as  part  of  the  command  which  enters 
the  absentee  request  ("ear"). 
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SCHEDULING  PERFORMANCE  TESTS 


An  absentee  control  program  or  exec_com  is  used  to  supervise  and 
control  the  entire  testing  procedure,  starting  from  the  point 
where  normal  user  service  is  suspended  right  on  through  to 
restoration  of  the  normal  service  following  the  dedicated 
operation.  Since  the  best  time  to  run  dedicated  tests  in  the 
RADC/Multics  environment  is  very  early  in  the  the  morning, 
normally  around  3AM,  it's  quite  practical  to  set  up  for  the 
machine-dedicated  execution  of  a performance  test  during  normal 
work  hours  and  have  execution  deferred  to  a more  benign  time. 

An  interactive  exec_com  called  "setup"  is  used  to  submit  the 
deferred  absentee  request  and  perform  some  housekeeping 
operations.  In  general  terms,  the  exec_com  performs  the 
following  functions: 

(1)  Delete  some  files  which  may  have  been  left  over  from 
execution  during  a previous  test  session,  and  make  sure  a 
zero-length  (null)  status  file  exists  for  the  upcoming  test. 

(2)  Ask  the  submitter  (see  Appendix  M)  what  time  he  would  like 
to  have  the  test  begin.  Store  his  response  in  a variable 
called  "valu". 

(3)  Enter  an  absentee  request  (called  "start_test" ) into  the 
highest  priority  queue,  queue  1,  after  the  following  questions 
are  asked  (see  Appendix  M) : 

(a)  How  many  processes  or  artificial  users  would  you  like 
to  have  logged  in  for  the  test?  (This  has  been  typically 
responded  to  with  the  number  15) 

(b)  How  many  load  iterations  would  you  like  each  artificial 
user  to  perform  before  the  test  terminates?  (Each 
artificial  user  serves  as  an  overseer  for  repeatedly 
executing  a relatively  brief  program  designed  to  place  a 
load  on  system  resources.  The  answer  to  this  question 
determines  the  number  of  times  each  overseer  will  execute 
the  load  program.) 

Defer  the  startup  of  the  test  until  the  time  specified  in  the 
stored  variable  "valu".  Three  arguments  will  be  passed  to  the 
control  program  when  it  finally  begins  execution.  The 
arguments  are  based  on  the  answers  to  the  questions  of  steps  2 
and  3. 
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(4)  Ask  the  submitter  (see  Appendix  M)  what  time  he  would  like 
Multics  to  restore  normal  operations  if,  for  some  reason,  the 
testing  procedure  fails  to  terminate.  Store  this  answer  in 
the  variable  "valu". 

(5)  Multics  runs  with  a privileged  and  very  powerful  control 
process  called  the  Initializer  System  Daemon  (typically  called 
the  Initializer).  In  this  step,  the  Initializer  is  instructed 
to  send  itself  a delayed,  executable  memo  to  the  effect  that, 
if  the  performance  test  hasn't  come  to  a normal  halt,  the  test 
is  to  be  aborted  and  normal  operations  are  to  be  restored. 
This  memo  becomes  active  or  "mature"  at  the  time  specified  in 
step  4,  and  induces  the  initializer  to  perform  as  indicated. 
However,  if  the  test  comes  to  a normal  conclusion  before  the 
memo  described  herein  matures,  the  system  will  have  already 
been  restored  to  normal  operations  and,  by  virtue  of  the  fact 
that  the  memo  is  recalled  or  deleted  as  part  of  this 
restoration  process,  no  test-abortion  memo  will  ever  get  the 
opportunity  to  mature. 

So,  in  summary,  the  setup  exec_com  performs  a little 
housekeeping,  schedules  a performance  test  to  run  at  some  time  in 
the  future,  and  caters  to  the  possibility  that  the  test  will  not 
terminate  properly. 


THE  GUESTS  MUST  LEAVE! 


When  the  time  arrives  for  the  absentee  control  program  to 
automatically  log  in  (typically  around  3AM  at  RADC ) , certain 
functions  must  be  performed  by  the  control  program  before  the 
machine  can  be  considered  dedicated  to  the  performance  testing 
procedure,  not  the  least  of  which  is  to  get  any  other  users  off 
the  system!  In  general  terms,  the  sequence  of  events  are  as 
follows : 

(1)  One  of  the  arguments  passed  to  the  absentee  control 
program  ( "star t_test" ) from  the  "setup"  exec_com  is  the  time 
said  control  program  was  scheduled  to  log  in,  plus  2 minutes. 
As  soon  as  the  control  program  does  log  in,  a check  is  made  to 
see  if  the  actual  log-in  time  is  less  than  the  value  passed  as 
an  argument.  If  it  is  not  less,  something  has  gone  amiss 
(perhaps  the  system  was  down  at  the  time  the  job  was  scheduled 
to  take  off)  and  the  session  is  aborted.  Recall,  if  you  will, 
that  a deferred  absentee  job  which  is  restricted  from  logging 
in  at  its  scheduled  time  will  be  allowed  to  log  in  at  its 
first  legitimate  opportunity. 

(2)  Set  a flag  indicating  that  the  test  session  is  now  in 
progress . 

(3)  Induce  the  Initializer  to  prevent  any  more  interactive 
users  from  logging  into  the  system. 

(4)  Warn  all  current  users  that  the  system  is  to  become 
unavailable  in  10  minutes.  They  are  asked  to  log  out  by  then. 
Pause  for  10  minutes. 

(5)  Bump  or  remove  all  bumpable  users  who  have  failed  to  log 
out . 

(6)  Log  out  all  special  system-support  users,  etc.  (except  the 
Initializer  System  Daemon)  which  serve  to  perform  various 
system  functions  like  10,  ARPA  Network  control,  etc. 

(7)  Execute  an  exec_com  which  alters  a table  controlling  the 
maximum  number  of  users  allowed  on  the  system  in  order  to 
permit  numbers  large  enough  to  accommodate  all  the  absentee 
users  who  might  possibly  be  logging  in  during  the  test 
session.  The  exec_com  also  restricts  absentee  queues  2 and  3 
from  allowing  jobs  to  log  in. 

(8)  Make  the  altered  table  become  immediately  effective. 


(9)  Query  Multics  as  to  all  interactive  users  who  may  still  be 
left  in  the  system,  and  place  the  results  of  this  query  into  a 
temporary  file.  (Two  types  of  users  can  conceivably  be  left  on 
the  system  despite  the  removal  processes  of  steps  5 and  6 — 
absentee  users,  and  interactive  users  who  are  not  bumpable  by 
the  method  used  to  accomplish  step  5 because  they  have  special 
privileges.)  Manipulate  this  temporary  file  with  an  editor 
such  that  the  file  will  take  on  the  format  of  an  executable 
editor  macro,  whereupon  execution  of  the  macro  will  perform 
the  user  bumps  which  couldn't  be  done  in  step  5. 


(10)  Query  Multics  as  to  all  absentee  users  who  may  still  be 
left  in  the  system,  and  place  the  query  results  into  a 
temporary  file.  Manipulate  this  temporary  file  with  an  editor 
such  that  the  file  will  take  on  the  format  of  an  executable 
editor  macro,  whereupon  execution  of  the  macro  will  bump  all 
absentee  users  from  the  system,  except  one!  Provisions  are 
made  to  prevent  the  absentee  job,  "star t_test" , which  is  in 
the  process  of  performing  all  this  stuff,  from  being  dislodged 
from  the  system.  Otherwise,  the  whole  process  will  end  very 
abruptly! 


(11)  Induce  the  Initializer  to  execute  an  exec_com  which  will 
logically  detach  all  phone  lines  from  the  system  answering 
service.  This  will  have  the  effect  of  making  it  unnecessary 
for  Multics  to  entertain  ringing  telephones  during  the  testing 
procedure.  Although  such  a load  might  not  be  considered  very 
large,  it  could  easily  have  undesirable  effects  on  test 
results.  The  goal  is  to  have  test  sessions  run  as  free  from 
any  outside  perturbations  as  possible. 


(12)  Prevent  the  accounting  program  from  making  any  updates 
during  the  testing  procedure.  This  will  eliminate  yet  another 
undesirable  load  from  the  system.  At  this  point,  Multics  is 
as  free  from  unwanted  intrusion  as  it  can  be.  All  the 
resources  can  be  dedicated  to  servicing  only  the  absentee 
users  who  will  soon  be  logging  into  the  system. 


(13)  Execute  an  exec_com,  called  "enter_all_abs_req" , which 
will  start  the  performance  test  rolling. 


When  the  exec_com  "enter_all_abs_req"  is  called  in  step  13  of  the 
previous  section,  three  arguments  are  passed  to  it.  The  first 
argument,  which  might  be  called  "TAKEOFF",  is  the  clock  time  at 
which  "enter_all_abs_req"  is  actually  called  in  aforesaid  step 
13,  plus  two  minutes.  "TAKEOFF"  will  be  the  clock  time  that  the 
multiple  absentee  load  overseers  will  simultaneously  log  in.  The 
second  argument,  which  might  be  called  "N",  represents  the  number 
of  absentee  jobs  (load  overseers)  that  will  be  logged  in  for  the 
duration  of  the  test.  This  is  the  typed  value  that  the  submitter 
responds  with  in  step  3a  of  section  "SCHEDULING  PERFORMANCE 
TESTS".  The  third  and  last  argument,  hereupon  named  "I"  (for 
Iterations) , is  the  number  of  times  each  load  overseer  will 
repeatedly  execute  a specific,  fixed  load  routine. 

The  four  operations  which  take  place  upon  execution  of  exec_com 
"enter_all_abs_req"  are  as  follows: 

(1)  Enter  "N"  absentee  requests,  each  representing  a load 

overseer.  The  names  of  these  absentee  jobs  are 

"load_overseer_l" , "load_overseer_2" , . . . , 

"load_overseer_N" , and  each  job  is  queued  up  in  absentee  queue 
1,  the  highest  priority  queue.  In  addition,  they  are  all 

i scheduled  to  be  deferred  until  "TAKEOFF".  Each  job  is  entered 

with  two  arguments  — the  first  argument  being  the  ID  of  the 
absentee  job  itself  (load_overseer_5  has  the  ID  "5"  associated 
with  it)  and  the  second  argument  being  "I". 

(2)  A termination  overseer  is  called  into  action  before 
"TAKEOFF".  This  program  coordinates  and  communicates  with  the 
absentee  load  overseers  through  a status  file.  It  is  called 
with  two  arguments,  "N"  and  "I",  and  its  job  is  to  (a)  set  a 
"termination  flag"  when  and  only  when  each  and  every  absentee 
load  overseer  has  performed  "I"  or  more  executions  of  the  load 
program,  and  (b)  summarize  the  data  passed  to  the  status  file 
by  each  load  overseer.  When  the  absentee  load  overseers  find 
the  termination  flag  set,  it  is  their  signal  to  store  their 
thruput  data  in  the  status  file  and  log  out  of  the  system. 
The  termination  overseer  waits  for  all  load  overseers  to  store 
their  thruput  results  in  the  status  file  before  it  summarizes 
the  data. 

(3)  The  exec_com  "compile_data"  is  called  with  the  argument 
"N".  It  collects  (and  in  one  case  compresses)  data  about  each 
of  the  absentee  overseers  for  subsequent  printing  (after  the 
system  has  been  restored  to  its  normal  operation) . It  also 
queues  for  printing  the  absentee  output  file  associated  with 
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"star t_test" . This  data  is  subsequently  examined  to  verify 
that  nothing  unusual  occurred  during  a given  test  session 
which  might  invalidate  results. 

(4)  Induce  the  Initializer  to  execute  an  exec_com  that 
restores  the  system  to  its  normal  user-support  status. 
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THE  FUNCTION  OF  THE  LOAD  OVERSEERS 


Except  for  its  ID  (see  step  1 of  previous  section) , each  absentee 
load  overseer  is  identical  to  all  the  others.  Each  of  them  calls 
the  same  routine  (named  "load_control")  with  two  arguments,  and 
when  this  routine  has  completed  its  execution,  control  is 
returned  to  the  appropriate  caller,  which  then  simply  logs  out  of 
the  system. 

As  an  introduction  to  the  actual  method  used  in  the  performance 
test  to  measure  total  thruput,  each  load  overseer,  by  virtue  of 
its  subordinate  program  "load_over seer " , executes  a "load"  "I" 
times.  Clock  times  are  taken  both  immediately  before,  and 
directly  after  each  execution  of  the  load,  and  the  difference 
between  the  two  is  added  to  a running  total.  Therefore,  after 
"I"  executions  of  the  load,  tV ->  • unning  total  contains  the  amount 
of  real  time  spent  in  executio-  f the  load.  If  this  running 
time  total  is  divided  into  t) ».  number  of  iterations,  "I",  which 
the  load  was  put  through,  then  value  with  the  dimensions 
"iterations  per  minute"  (IPM)  ^ derived.  The  summation  of  the 
various  IPM's  for  all  "N"  load  overseers  represents  the  total 
thruput,  in  iterations  per  minute,  managed  by  the  Multics 
hardware/software  configuration  at  the  time  of  the  test.  This 
figure  can  then  be  used  as  a benchmark  for  certain  comparisons, 
depending  on  what  an  analyst  has  in  mind  and  also  on  the  nature 
of  the  "load"  (which  will  be  discussed  later) . 

The  first  argument  passed  to  "load_control"  (which  is  shared 
amongst  the  "N"  load  overseers)  is  the  ID  number  of  the  load 
overseer  calling  it,  and  the  second  argument  is  "I",  the  number 
of  iterations  through  which  the  load  will  be  placed.  The 
load_control  program  performs  the  following  functions: 

(1)  After  doing  a little  housekeeping,  load_control  executes 
the  load  by  calling  the  routine  "load"  (which  is  also  shared 
amongst  the  "N"  load  overseers).  However,  the  real  time  used 
to  execute  this  first  call  is  not  added  to  the  running  total, 
nor  is  it  considered  to  be  one  of  the  required  "I"  iterations. 
This  initial  call  serves  only  to  "prime"  all  the  Multics 
hardware  and  software  mechanisms  for  the  activity  to  follow. 

(2)  Perform  "I"  executions  of  the  load,  keeping  a running 
total  of  the  real  time  involved. 

(3)  The  status  file  which  the  termination  overseer  uses  to 
communicate  with  each  of  the  load  overseers  has  "N"  slots  in 
it,  each  of  them  eight  ascii  characters  in  width.  The 
numbered  slot  which  a particular  load  overseer  uses  to  pass 
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information  to  the  termination  overseer  is  the  same  as  the 
load  overseer's  ID.  When  step  2 has  run  to  completion,  the 
load  control  program  writes  the  word  "finished"  in  its 
appropriate  slot  in  the  status  file,  and  when  the  termination 
overseer  finds  the  word  "finished"  in  all  "N"  slots  of  the 
status  file,  it  sets  the  "termination  flag". 

(4)  There  is  very  likely  to  be  a delay  between  the  time  a 
particular  load  control  program  writes  "finished"  in  the 
status  file  and  the  time  the  termination  overseer  sets  the 
termination  flag.  There  are  two  reasons  for  this  delay,  the 
first  being  that  the  termination  overseer  only  senses  the 
contents  of  the  status  file  every  30  seconds,  and  the  second 
being  that  one  or  more  other  load  control  programs  may  still 
be  executing  one  of  its  "I"  load  iterations  (the  load  control 
programs  do  not  run  in  exact  unison,  despite  the  overseers 
having  logged  in  simultaneously).  In  any  case,  results  would 
be  distorted  if  any  one  or  more  load  control  programs  just 
stopped  executing,  after  it  had  completed  its  "I"  passes, 
while  others  were  still  running.  Therefore,  in  this  step,  the 
load  control  program  looks  for  the  setting  of  the  termination 
flag,  and  if  not  found,  executes  the  load  once  again.  This 
will  continue  until  the  termination  flag  is  found  to  be  set, 
at  which  time  the  program  proceeds  to  the  next  step. 

(5)  Calculate  IPM  and  write  it  into  the  appropriate  slot  of 
the  status  file.  Then  return  control  to  the  absentee  overseer 
(which  thereupon  logs  out) . 


THE 


LOAD" 


The  load  which  each  of  the  "N  absentee  load  overseers  imposes  on 
the  system  "I"  times  is  designed  by  the  analyst  to  exercise  those 
elements  of  Multics  (hardware  and/or  software)  which  are  to  be 
benchmarked  for  future  comparisons.  It  is  not  the  purpose  of 
this  report  to  discuss  what  kind  of  loads  should  be  used  for 
whatever  purposes,  since  such  determinations  are  far  from 
trivial.  But,  in  general,  it  can  be  said  that  if  one  anticipates 
some  kind  of  change  in  one  or  more  elements  of  his 
hardware/software  configuration,  and  it  is  desirable  to  determine 
whether  or  not  that  change  has  a positive  or  negative  effect  on 
system  performance,  then,  by  a judicious  choice  of  a "load",  he 
can  make  "before  and  after"  comparisons. 

At  RADC , a very  simple  load  program  has  been  used  repeatedly 
which,  from  experience,  seems  to  predict,  with  a reasonable 
degree  of  accuracy,  percentage  changes  in  normal  user  thruput 
when  changes  in  hardware  configurations  are  made.  That  PL/1 
program  is  as  follows: 


load:  proc; 

del  a(1024)  fixed  bin(35); 

del  flush  entry; 

del  (j,  k,  sum)  fixed  bin(35); 

call  flush; 

do  j * 1 to  100; 

do  k * 1 to  1024; 
a (k)  = 12345; 
sum  = sum  + a (k) ; 
end ; 

end ; 

end  load; 


It  is  not  likely  that  other  Multics  sites  would  find  this 
particular  program  as  useful  as  has  RADC,  but  the  idea  of  trying 
to  develop  one  with  a great  deal  of  simplicity  is  aesthetically 
pleasing. 
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SUMMARY 


This  report  has  discussed  how  a certain  type  of  performance  test 
may  be  automated  at  sites  being  supported  by  Honeywell/Multics 
computer  systems.  The  primary  value  of  this  automation  is  the 
ability  to  provide  dedicated,  unsupervised  sessions  during  shifts 
which  are  typically  not  manned  by  support  personnel,  and  which 
have  the  least  impact  on  users. 

It  has  been  shown  that  the  Multics  absentee  facility,  when 
exercised  by  a user  who  has  special  access  to  a few  privileged 
Multics  commands  or  routines,  can  be  used  to  support  dedicated 
sessions  with  normal  users  being  supported  directly  preceding  and 
directly  following  such  sessions.  Furthermore,  the  fail-soft 
design  of  the  procedure  discussed  herein  insures  a minimum  of 
lost  time  should  a particular  performance  test  fail  to  run  to 
completion  for  some  reason. 


DETAILS 


This  section  deals  with  specific  details  of  implementation  of  the 
procedure  which  has  been  discussed.  Seasoned  Multics  users  will 
be  able  to  understand  the  details  that  follow. 

The  working  directory  in  which  the  functions  discussed  in  this 
report  are  performed  is  >udd>sa>e>lt.  It  must  contain  the 
following  four  segments  at  the  outset  (setup. ec  has  7 added 
names)  : 

load_control 

load 

termination_over seer 
setup. ec 

start_test .absin 
enter_al l_abs_rec . ec 
compile  data.ec 
set_con7ig_table .ec 
restore_normal_operat ions . ec 
attach_phone_lines.ec 
detach_phone_l ines .ec 

The  segment  "setup. ec"  actually  contains  all  the  exec_coms  and 
absin  programs  indicated  by  the  multiple  names  above.  The 
convention  of  tacking  many  exec_coms  together  and  then  using  a 
"&goto  &ec_name"  (with  appropriate  entry  labels)  was  used  to 
simplify  maintenance  of  the  software.  However,  they  may 
equivalently  fce  broken  up  into  eight  separate  segments  and  dealt 
with  in  that  way.  In  any  case,  the  appendix  listings  and 

descriptions  of  the  exec_coms  will  be  handled  separately  for  the 
purpose  of  clarity  in  presenting  this  report. 

Three  subdirectories  exist  below  >udd>sa>e>lt.  They  are  (with 
added  names) : 

source 

load_overseer_N. absin 
absin 

load_overseer_N.absout 

absout 

The  source  directory  contains  the  PL/1  source  segments  for  the 
three  object  segments  "termination_overseer " , "load",  and 
"load_control" . The  absin  directory  contains  32  load  overseer 
absin  segments  (numbered  1 through  32) , and  the  absout  directory, 
empty  at  the  beginning  of  a given  session,  is  used  to  house  the 
load  overseer  absentee  output  segments  as  they  are  created. 
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The  declaration  limits  of  the  based  variable  "ipm_status  seg"  in 
the  " termination_overseer " and  "load_control"  programs  allow  for 
up  to  32  slots  in  the  status  segment.  In  concert  with  this,  32 
absentee  input  segments  exist  in  the  directory  "absin"  to  allow 
for  up  to  32  absentee  load  overseers  to  be  logged  in  during  a 
particular  session.  Fifteen  are  normally  used  at  RADC. 

All  the  load  overseer  absin  segments,  identical  except  for  name, 
contain  the  following  three  lines: 

cwd  >udd>sa>e>lt 
load_control  &1  & 2 
Squit 


setup. ec 

The  exec_com  "setup"  is  listed  in  Appendix  A,  and  its  functional 
description  is  covered  in  the  section  SCHEDULING  PERFORMANCE 
TESTS.  Two  comments  may  be  necessary  at  this  point  to  clarify 
the  exec_com. 

First,  the  active  function  "valu"  is  a general  purpose  PL/1 
utility  program  written  at  RADC.  It  allows  one  to  reset  an 
internal  static  ascii  variable  (initially  null)  through  the 
"reset"  entry,  to  print  it's  value  via  the  "print"  entry,  and  to 
use  the  value  by  using  the  active  function.  If  one  simply  types 
"valu",  instructions  for  usage  are  given.  The  program  is  listed 
in  Appendix  B. 

Second,  the  "sac"  or  "send_admin_command"  is  used  by  privileged 
Multics  users  to  request  that  the  Initializer  perform  a function 
in  its  own  domain.  The  sac  command  is  used  extensively  in  the 
software  described  in  this  report,  particularly  in  conjunction 
with  "sc_command" , which  is  available  only  to  the  Initializer. 
The  routine  "sc_command"  is  used  by  the  Initializer  process  to 
execute  those  functions  normally  typed  at  the  Initializer  under 
the  system  control  mode  by  operators. 


start_te st. absin 

A general  description  of  the  function  of  "start_test. absin"  is 
given  under  the  section  "THE  GUESTS  MUST  LEAVE!",  and  a listing 
may  be  found  in  Appendix  C.  Additional  clarification  of 
"start_test .absin"  follows: 

In  line  4,  a flag  is  set  in  the  Initializer's  process  directory 
to  indicate  that  the  test  is  under  way.  The  purpose  for  setting 
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it  in  the  process  directory  is  that  it  will  disappear  if  the 
system  should  crash.  It  is  important  that  the  flag  not  be 
present  after  a crash  and  reboot,  else 

"restore_normal_operations.ec"  will  begin  executing  when  it 
shouldn't  (the  results  of  the  "If-failure"  memo  entered  in 
"setup. ec") . 

In  line  8 of  start_test.absin,  the  exec_com  "initl"  is 

referenced.  It  is  used  to  send  the  Initializer  a command  which 
is  longer  than  the  "sac"  or  "send_admin_command"  can  handle.  It 
is  listed  here: 

&command_l ine  off 
&input_line  off 
sattach 
qx 

r >scl>execute_long_command .ec 
2c 

sc_command  &1  & 2 &3  &4  &5  &6  &7  &8  &9  &10  &11  &12  &13  &14  &15 

{continuation  of  previous  line}  &16  &17  &18 
\f 


sac  ec  execute_long_command 
&quit 

The  exec_com  "execute_long_command"  under  >scl  contains  three 
lines,  the  first  being  "&command_line  off",  the  third  being 
"&quit",  and  the  second  being  that  which  is  manipulated  by 
initl.ee  above. 


In  line  42  of  start_test.absin,  the  absentee  user  "Elefante"  is 
deleted  from  the  editor  buffer  to  prevent  his  being  bumped  when 
the  file  is  executed  as  an  editor  macro.  The  exec_coms 
"set_conf ig_table"  and  "detach_phone_lines"  can  be  found  in 
appendices  D and  E,  respectively. 


An  Initializer  call  to  "act_ctl_$act 
two  lines  from  the  end  of  star 
Release  4.0  provides  this  entry  for 
account  charging,  but  it  does  not  di 
allows  wakeups  at  fixed  interval 
sessions) . Also,  when  accounting 
"act_ctl_$act_ctl_reable"  entry,  a t 
which  forces  accounting  to  go  into 
for  the  remainder  of  the  system-up 
abnormal  messages  at  the  Initialize 
these  problems,  "act_ctl_"  has  been 
ascii  comparison  of  the  old  source 


_ctl_noupdate"  can  be  found 
t_test .absin . Multics  System 
the  purpose  of  turning  off 
sable  the  event  channel  which 
s (not  desirable  during  test 
is  re-enabled  via  the 
ime  discrepancy  is  calculated 
a periodic  manual  update  mode 
period,  and  to  print  out 
r.  In  order  to  avoid  both  of 
modified  at  RADC , and  an 
(standard  SR4.0  version)  with 


the  new  source  (modified  4.0  version)  is  found  in  Appendix  F. 


FT 


r estore_normal_ope rat ions ,ec 

A copy  of  this  exec_com  can  be  found  in  Appendix  G.  Line  2 
checks  to  see  if  the  test  is  still  in  progress.  Normally  it  will 
be,  but  if  the  system  crashes  after  the  test  starts,  and  before 
normal  operations  are  restored,  the  segment  "test_in_progress" 
will  vanish  from  the  Initializer's  process  directory  upon 
rebooting.  Without  this  segment  in  existence,  the  "if-failure" 
memo  will  perform  harmlessly,  for  it  is  not  very  wise  to  have  the 
system  restored  to  normal  operations  by  this  exec_com  when  it  is 
already  operating  normally! 

Line  4 deletes  "test_in_progress"  from  the  process  directory,  and 
line  5 removes  the  "if-failure"  memo  from  the  Initializer's  memo 
segment  (not  necessary,  but  cleaner) . 

Line  7 calls  the  FADC-modif ied  version  of  "act_ctl_M  (see  last 
paragraph  under  the  "star t_test .absin"  heading  in  this  section). 

The  exec_com  "attach_phone_l ines"  causes  Multics  to  begin 
answering  telephones  once  again  (they  were  disabled  in 
"setup. absin") . 

The  exec_com  "retype_conf ig^table"  restores  the  configuration 
table  in  the  system  installation  parameters  segment  which  were 
modified  in  "setup. absin" . This  exec_com  is  placed  under  >scl  at 
RADC  because  it  is  sometimes  used  in  other  situations.  A listing 
is  found  in  Appendix  H. 
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Appendix  A (setup. ec) 


1 


t 


&command_line  off 
delete  start_test.absout 
answer  yes  -bf  dl  absout>** 
delete  termination_f lag 

&if  [not  [exists  segment  ipm_status_seg] ] 

Sthen  create  ipm_status_seg 
seise  truncate  ipm_status_seg 
valu$reset  [response  Start_time?] 
ear  start_test  -q  1 -bf  -tm  [valu] 

% -ag  [date_time  [valu]  2 minutes]  [response  "#  of  processes?"] 

% [response  "#  of  load  iterations?"] 

valuSreset  [response  "If-failure  restore  time?"] 

sac  memo  -al  -tm  [valu]  -call  ec  >udd>sa>e>lt>restore_normal_ 

%operations 

Squit 


"%"  used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 


Appendix  B (valu.pll) 


valu:  proc; 

del  cu_$af_return_arg  entry 

% (fixed  bin,  ptr,  fixed  bin,  fixed  bin(35)); 
del  return_str ing  char (max_length)  varying 
% based (return_str ing_ptr) ; 
del  return  string_j?tr  ptr; 
del  nargs  "Fixed  bin; 

del  cu_$af_arg_count  entry  (fixed  bin,  fixed  bin (35)); 
del  max_length  fixed  bin; 
del  ap  ptr  init(null); 
del  code  fixed  bin(35); 

del  cu_$arg_ptr  entry  (fixed  bin,  ptr,  fixed  bin,  fixed  bin  (35) ) ; 
del  input_arg  char (132)  based (ap); 
del  ioa_  entry  options (var iable) ; 
del  null  builtin; 

del  valu  char (132)  varying  int  static; 
del  valu_length  fixed  bin  int  static; 

call  cu_$af_arg  count  (nargs,  code) ; 
if  code  ~=  0 then  do; 

call  ioa_  ("''/Subroutine  ""valu""  must  be  called  as  an 
% active  function  with  no  arguments."); 

call  ioa_  ("Other  entry  points  are  as  follows :“/") ; 
call  ioa_  ( " -'-valu$reset'>-Fesets  the  value  of  an 
% internal  static  character  string  variable 
“3- ( initially  null)  for  subsequent  active  function  calls"); 

call  ioa_  ("~-valu$print~-Prints  (enclosed  in  double 
% quotes)  the  value  of  the 
~3-internal  character  string  variable-'/"); 
end ; 

else  do; 

call  cu_$af_return_arg  (nargs,  r eturn_str ing_ptr , 

% max_length,  code) ; 

return_str ing  = substr  (valu,  1,  valu_length) ; 
end ; 


return ; 


call  cu_$arg_ptr  (1,  ap,  valu_length,  code); 
if  ap  = null  then  valu_length  = 0; 
else  valu  = substr  (input_arg,  1,  valulength) ; 
return ; 
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print:  entry; 

call  ioa_  ("V"*va ""V,  valu_length,  valu)  ; 
return; 

end  valu; 

used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 
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^attach 

&if  [greater  [date_time)  "&1"]  &then  ioa_  "Test  took  off  too 
% late.  Abort!";  rl 
cwd  >udd>sa>e>lt 

sac  cr  >pdd> ! zzzzzzzbBBBBBB>test_in_progress 
pause  10 

sac  sc_command  word  test  Special  test  session  in  progress 
pause  10 

ec  >udd>sa>e>t>initl  w * * System  will  become  unavailable  in  10 
% minutes.  Please  log  out  by  then, 
pause  600 

sac  sc_command  bump  * * 
pause  30 

sac  ec  admin  netdown 
pause  10 

sac  sc_command  logout  * 
pause  20 

ec  set_config  table 
sac  sc_commancT  maxu  auto 
pause  10 
truncate  ot 

fo  ot;as_who  -interactive  -long;co 

qedx 

r ot 

1,3d 

$d 

l,$s/A // 

l,$s/A /&%/ 

l,$s/%.*$/%e  pause  10/ 
l,$s/A/e  sac  sc_command  bump  / 
l,$s/%/\c 
/ 

\b0 

e pause  10 

q 

truncate  ot 

fo  ot;as_who  -as;co 

qedx 

r ot 

$d 

1, $s/  (.*$/%e  pause  10/ 
l,$s/\c./  / 

l,$s/A/e  sac  sc_command  abs  bump  / 
gd/Elefante/ 
l,$s/%/\c 
/ 
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\b0 

e pause  10 

q 

sac  ec  >udd>sa>e>lt>detach_phone_lines 
pause  5 

sac  act__ctl_$act_ctl_noupdate 

ec  enter_all_abs_req  [da^_time  2 minutes]  &2  &3 
&quit 


used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 
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Appendix  D (set_conf ig_table .ec) 


. • 

t 


&command_line  off 
&input_line  off 
Sattach 

ed_installation_parms  >scl>installation_parms 


r 

conf 

1 

512 

0 

1 

0 

41.0 

41.0 

40 

1 

1 

512 

0 

2 

0 

41.0 

41.0 

40 

1 

1 

512 

0 

3 

0 

41.0 

41.0 

40 

1 

1 

512 

0 

4 

0 

41.0 

41.0 

40 

1 

1 

768 

0 

1 

0 

41.0 

41.0 

40 

1 

1 

768 

0 

2 

0 

41.0 

41.0 

40 

1 

1 

768 

0 

3 

41.0 

41.0 

40 

1 

1 

768 

0 

4 

0 

41.0 

41.0 

40 

1 

2 

512 

0 

1 

0 

41.0 

41.0 

40 

1 

2 

512 

0 

2 

0 

41.0 

41.0 

40 

1 

2 

512 

0 

3 

0 

41.0 

41.0 

40 

1 

2 

512 

0 

4 

0 

41.0 

41.0 

40 

1 

2 

768 

0 

1 

0 

41.0 

41.0 

40 

1 

2 

768 

0 

2 

0 

41.0 

41.0 

40 

1 

2 

768 

0 

3 

0 

41.0 

41.0 

40 

1 

2 

768 

0 

4 

0 

41.0 

41.0 

40 

1 

0 

w 

q 

Sdetach 

Squit 
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Appendix  E (detach_phone_lines .ec) 


&command_line  off 
Sprint  detaching 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc_command  remove 
sc  command  remove 


telephone  lines 
net001 
net002 
net003 
net004 
net005 
net006 
net007 
net008 
net009 
net010 
net011 
net012 
net013 
net014 
net015 
net016 
net017 
net018 
net019 
net020 
tty000 
tty001 
tty002 
tty003 
tty004 
tty005 
tty006 
tty007 
tty008 
tty009 
tty010 
tty011 
tty012 
tty013 
tty014 
tty015 
tty016 
tty017 
tty018 
tty201 
tty202 
tty203 
tty205 
tty206 
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sc_command  remove  tty207 
sc_command  remove  tty208 
sc_command  remove  tty209 
sc_command  remove  tty210 
sc_command  remove  tty211 
sc_command  remove  tty212 
sc_command  remove  tty213 
sc_command  remove  tty214 
sc_command  remove  tty215 
sc_command  remove  tty216 
sc_command  remove  tty217 
sc_command  remove  tty218 
sc_command  remove  tty600 
sc_command  remove  tty601 
sc_command  remove  tty602 
sc_command  remove  tty605 
sc_command  remove  tty616 
sc_command  remove  tty617 
sc_command  remove  tty620 
sc_command  remove  tty621 


Appendix  F 

(ascii  comparisons  of  modifications  to  act_ctl_.pll) 
("A"  represents  old  source,  "B"  new  source) 


B143  timer_manager_$reset_alarm_wakeup  entry 

% (fixed  bin  (71) ) , 

Inserted  before: 

A143  (sys_log_,  sys_log_$er ror_log)  entry  options 

% (var iable)  , 


B787 

% 

B788 

% 

B789 

% dd,  yy, 
B790 
« 

B791 


hh,  min. 


% next_update) ; 


updatetime  = anstbl .cur rent  time ; 

/*  Set  time  of  last  update.  */ 
anstbl .current_time  = clock_  (); 

/*  Bead  clock.  */ 

call  datebin_  (anstbl . cur rent_time , absda,  mm 
sss,  wkd,  shf); 
anstbl. shift  = shf; 

/*  Save  current  shift  */ 
call  datebin_$revert  (mm,  dd , yy,  hh,  0,  0, 


B792  do  while  (next_update  < anstbl ,current_time) ; 

% /*  Compute  next  update  time  */ 

B793  next_update  = next_update  + 

% installation_parms.acct_update*MILLION; 

B794  end; 

B795  call  timer  jnanager_$alarm_wakeup  (next_update 

% "00"b,  updchn) ; 

B796  last_update_interval  = 

% installation_parms .acct_update ; 


% /*  Save  for  clock  check  (in  case  inst_parms  changes)  */ 


9 


9 


Inserted  before: 

A786  call  sys_log_  (1,  "act_ctl_:  accounting 

% enabled."); 


B804  call  timer_manager_$reset_alarm_wakeup 

% (updchn) ; /*  destroys  wakeup  */ 

Inserted  before: 

A793  call  sys_log_  (1,  "act_ctl_:  accounting  update 

% disabled. ") ; 
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&command_line  off 

&if  [not  [exists  segment  >pdd> ! zzzzzzzbBBBBBB>test_in_progress] J 
Sthen  &quit 

delete  >pdd> ! zzzzzzzbBBBBBB>test_in_pr ogress 
memo  -dl  -match  restore_normal_operations 
ioa_  2/re storing  normal  operations" 

act_ctl_$act_ctl_reable 
sc_command  abs  bump  * * 
ec  >udd>sa>e>lt>attach_phone_l ines 
sc_command  word  login 

sc_command  login  Networ k_Daemon  SysDaemon  nw 
sc_command  login  Networ k_Server  NetAdmin  ns 
sc_command  login  Backup  SysDaemon  bk 
sc_command  login  10  SysDaemon  cord 
sc_command  login  10  SysDaemon  prta 
sc_command  login  10  SysDaemon  puna 
pause  30 

sc_command  r cord  coordinator 
sc_command  r prta  driver 
sc_command  r puna  driver 
pause  30 

sc_command  r prta  prta 
sc_command  r puna  puna 
ec  retype_conf ig_table 
sc_command  maxu  auto 

answer  yes  -bf  dp  -bf  >udd>sa>e>lt>absout>dataseg 
answer  yos  -bf  dp  -bf  >udd>sa>e>lt>absout>absout. archive 
answer  yes  -bf  dp  -bf  >udd>sa>e>lt>start_test .absout 
&quit 


"%"  used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 
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Appendix  H (retypeconf ig_table.ec) 


&command_l ine  off 
Sattach 

ed_installation_parms  >scl>installation_parms 
r conf 

1 512  0 1 0 21.5  21.5  1 1 

1 512  0 2 0 21.5  21.5  5 3 

1 512  0 3 0 21.5  21.5  5 3 


1 768  0 1 0 23.5  23.5  1 1 

1 768  0 2 0 23.5  23.5  5 3 

1 768  0 3 0 23.5  23.5  5 3 

2 512  0 1 0 26.5  26.5  1 1 

2 512  0 2 0 26.5  26.5  5 3 

2 512  0 3 0 26.5  26.5  5 3 

2 768  0 1 0 31.5  31.5  1 1 

2 768  0 2 0 31.5  31.5  5 3 

2 768  0 3 0 31.5  31.5  5 3 

0 

w 

q 

Sdetach 

&quit 


Appendix  I (star t_test .absin) 

scl  500 

ear  load_overseer_ ( ( index_set  &2]) 

% -bf  -q  1 -tm  "&1"  -ag  ([index__set  &2])  &3 
scl 

Itermination_overseer  & 2 &3 
ec  compile_data  &2 

sac  ec  >udd>sa>e>lt>restore_normal_operations 
&quit 


"%"  used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 

I 
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Appendix  J (compile_data .ec) 


y 


^attach 

cwd  >udd>sa>e>lt>absout 
scl  500 

ac  ad  absout  load_over seec_ ( [ index_set  &1]). absout 

scl 

qedx 

bt 

r <start_test .absout 
vd/Thruput  for/ 
b0 

r absout. archive 
vd/Iterations/ 

$a 

\bt 

\f 

e fo  ot;pcd;co 
be 
r ot 

1 f/^cpuZ-ld 

/*clok/,$d 

b0 

a\bc\f 
w dataseg 

q 

cwd  < 

&quit 


Appendix  K ( termination_over seer .pll) 


termination_overseer : proc (ascii_n_loads,  ascii_n_iterations)  ; 

del  ascii_n_loads  char(*); 
del  ascii_n_iterations  char(*); 
del  character_value  char  (7); 
del  code  fixed  bin(35); 

del  cv_dec_check_  entry  (char(*),  fixed  bin(35)) 

% returns  (fixed  bin(35)); 

del  cv_float_  entry  (char(*)»  fixed  bin(35),  float  bin(27)); 
del  fpsum  float  bin(27); 
del  fpval  float  bin(27); 

del  get_wdir_  entry  returns  (char  (168)  aligned); 

del  hcs_$initiate  entry  (char(*),  char(*),  char(*),  fixed  bin(l), 
% fixed  bin(2),  ptr,  fixed  bin(35)); 

del  hcs_$make_seg  entry  (char(*),  char(*),  char(*),  fixed  bin(5), 
% ptr,  fixed  bin(35)); 
del  i fixed  bin; 

del  ioa_  entry  options (var iable) ; 

del  ipm_status_seg (32)  char  (8)  based  (status_ptr ) ; 

del  n_loads  fixed  bin (35); 

del  n_iterations  fixed  bin(35); 

del  null  builtin; 

del  status_ptr  ptr; 

del  substr  builtin; 

del  termination_f lag_ptr  ptr; 

del  timer_manager_$sleep  entry  (fixed  bin(71),  bit(2) ) ; 

n loads  * cv_dec_check_  (ascii_n_loads , code); 

If  code  **  0 then  do; 

call  ioa_  ("Bad  argument  1 input  to 
% termination_overseer . Abort."); 

call  hes  $make_seg  ( (get_wd ir_ ( ) ) , "termination_f lag" , 

% 10,  termination_f lag_ptr , code); 

return; 
end ; 

n_iterations  * cv_dec_check_  (ascii_n_iterations , code); 
if  code  A=  0 then  do; 

call  ioa_  ("Bad  argument  2 input  to 
% termination_overseer . Abort."); 

call  hcs_$make_seg  ( (get_wd ir_ ( ) ) , " terminat ion_f lag" , 

% 10,  termination_f lag_ptr , code); 

return ; 
end ; 

status_ptr  = null; 


IUuM 


call  hcs_$initiate  ( (get_wd ir_ ( ) ) , " ipm_status_seg" , 

% , 0,  0,  status_ptr,  code); 

if  status  ptr  = null  then  do; 

call  Toa_  ("Unable  to  initiate  ipm_status_seg . 

% Abort."); 

call  hcs_$make_seg  ( (get_wdir_() ) , "termination_f lag” , 

% 10,  termination_f lag_ptr , code); 

return; 
end ; 

do  i * 1 to  n_loads; 

ipm_status_seg ( i)  = "ZZZZZZZZ"; 
end ; 

do  i = 1 to  n_loads; 

do  while  ( ipm_status_seg ( i)  = "ZZZZZZZZ"); 
call  timer_manager_$sleep (30 , "ll"b) ; 
end ; 

end ; 

termination_f lag_ptr  = null; 

call  hcs_$make_seg  ( (get_wdir_ ( ) ) , "termination_f lag" , "", 

% 10,  termination_f lag_ptr , code); 

call  timer_manager_$sleep (30 , "ll"b)  ; 

do  i = 1 to  n_loads; 

do  while  ( ipm_status_seg ( i)  = "finished"); 
call  timer_manager_$sleep (30 , " 11 "b) ; 
end ; 

end ; 

fpsum  = 0 . ; 

do  i = 1 to  n_loads; 

character_value  = substr ( ipm_status_seg ( i) , 1,  7); 
call  cv_float_  (character_value , code,  fpval) ; 
fpsum  = fpsum  + fpval; 
end ; 

call  ioa_  ("~3/*****  Thruput  for  ~d  loads  and  ~d  iterations 
% is  *.4f  iterations  per  minute  *****“3/",  n_loads,  n_iterations , 
**  fpsum)  ; 

end  termination  overseer; 


"%"  used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 


35 


. 

!r 
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Appendix  L (load_control .pll) 


load_control : proc; 

del  ap  ptr; 

del  ascii_load_id  char  (2)  based (ap) ; 
del  ascii_iteration_cutof f char (4)  based (ap); 
del  clock_  entry  returns  (fixed  bin(71)); 
del  code  fixed  bin(35); 

del  cu_$arg_ptr  entry  (fixed  bin,  ptr,  fixed  bin,  fixed  bin(35)); 
del  finish_time  fixed  bin(71); 
del  fixed  builtin; 
del  float  builtin; 

del  get_wdir_  entry  returns  (char (168)); 

del  hcs_$initiate  entry  (char(*),  char(*),  char(*),  fixed  bin(l), 
% fixed  bin(2),  ptr,  fixed  bin(35)); 

del  hcs_$make_seg  entry  (char(*),  char(*),  char(*),  fixed  bin (5), 

% ptr,  fixed  bin(35)); 

del  ioa_  entry  options (var iable) ; 

del  ioa_$rs  entry  options (var iable) ; 

del  ipm  float  bin; 

del  ipm_status_seg (32)  char  (8)  based (status_ptr) ; 

del  iteration_count  float  bin; 

del  iteration_cutof f float  bin; 

del  len  fixed  bin(17); 

del  load  entry; 

del  load_id  fixed  bin (35); 

del  null  builtin; 

del  start_time  fixed  bin(71); 

del  status_ptr  ptr; 

del  substr  builtin; 

del  termination_f lag_ptr  ptr; 

del  total_minutes  float  bin; 

del  total_time  fixed  bin(71); 

call  cu_$arg_ptr  (1,  ap,  len,  code); 
if  code  ~=  0 then  do; 

call  ioa_  ("Problem  with  argument  1.  Abort."); 

call  hcs_$make_seg  ( (get_wd ir_ ( ) ) , "termination_f lag" , 

% 10,  termination_f lag_ptr , code); 

return ; 
end ; 

load_id  = fixed (substr (asci i_load_id , 1,  len),  35); 

call  cu_$arg_ptr  (2,  ap,  len,  code); 
if  code  “=  0 then  do; 

call  ioa_  ("Problem  with  argument  2.  Abort."); 
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call  hcs_$make_seg  ( (get_wdir_() ) , " termination_f lag" , 
% "",  10,  termination_flag_ptr , code); 
return ; 
end ; 

iteration_cutof f = float (substr (ascii_iteration_cutof ',  1, 
% len),  27); 

total_time  = 0; 
total_minutes  = 0.; 
status_ptr  = null; 

call  hcs_$initiate  ( (get_wd ir_ ( ) ) , " ipm_status_seg" , 

% 0,  0,  status_ptr,  code); 

if  status_ptr  = null  then  do; 

call  ioa_  ("No  ipm_status_seg . Abort."); 

return; 

end ; 

call  load; 

do  iteration_count  = 1.0  to  iteration_cutof f by  1.0; 
start_time  = clock_(); 
call  load; 

finish_time  = clock_() ; 

total_time  = total_time  + (finish_time  - start_time) ; 
end; 

ipm_status_seg (load_id)  = "finished"; 
termination_f lag_ptr  = null; 

do  while  (termination_f lag_ptr  = null)  ; 
call  load; 

call  hcs_$ initiate  ( (get_wd ir_ ( ) ) , "termination_f lag" , 
% "",  0,  0,  termination_f lag_ptr , code); 
end ; 

total_minutes  = float (total_time,  27) /6000000O . ; 
ipm  = iteration_cutof f/total_minutes ; 

call  ioa_$rs ("*7.4f " , ipm_status_seg (load_id) , len,  ipm); 
call  ioa_  ("Iterations/minute  for  load  ~2d  = A7.4f", 

% load_id,  ipm); 

end  load  control; 


"%"  used  at  beginning  of  line  indicates  continuation  of  previous 
line  (but  line  not  broken  in  actual  implementation) 
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Appendix  M 

(Sample  terminal  session  for  job  setup) 


ec  setup 

Start_time?  0300. 

# of  processes?  15 

# of  load  iterations?  50 


(initiates  question  sequence) 


If-failure  restore  time?  0600. 


Mrruc  SYSTEM 


BASE  UNITS: 

Quantity 


Unit 


SI  Symbol  Formula 


length 

metre 

m 

mass 

kilogram 

kg 

time 

second 

8 

electric  current 

ampere 

A 

thermodynamic  temperature 

kelvin 

K 

amount  of  substance 

mole 

mol 

luminous  intensity 

candela 

cd 

SUPPLEMENTARY  UNITS: 

plane  angle 

radian 

rad 

solid  angle 

steradian 

sr 

DERIVED  UNITS: 

Acceleration 

metre  per  second  squared 

activity  (of  a radioactive  source) 

disintegration  per  second 

angular  acceleration 

radian  per  second  squared 

angular  velocity 

radian  per  second 

area 

square  metre 

density 

kilogram  per  cubic  metre 

electric  capacitance 

farad 

F 

electrical  conductance 

siemens 

S 

electric  field  strength 

volt  per  metre 

H 

electric  inductance 

henry 

electric  potential  difference 

volt 

V 

electric  resistance 

ohm 

electromotive  force 

volt 

V 

energy 

joule 

) 

entropy 

joule  per  kelvin 

N 

force 

newton 

frequency 

hertz 

Hz 

illuminance 

lux 

lx 

luminance 

candela  per  square  metre 

1m 

luminous  flux 

lumen 

magnetic  field  strength 

ampere  per  metre 

Wb 

magnetic  flux 

weber 

magnetic  flux  density 

tesla 

T 

magnetomotive  force 

ampere 

A 

power 

watt 

W 

pressure 

pascal 

Pa 

quantity  of  electricity 

coulomb 

C 

quantity  of  heat 

joule 

I 

radiant  intensity 

watt  per  steradian 

specific  heat 

joule  per  kilogram-kelvin 

Pa 

stress 

pascal 

thermal  conductivity 

watt  per  metre-kelvin 

velocity 

metre  per  second 

viscosity,  dynamic 

pascal-second 

viscosity,  kinematic 

square  metre  per  second 

voltage 

volt 

V 

volume 

cubic  metre 

wavenumber 

reciprocal  metre 

work 

joule 

i 

m/s 

(disintegration  )/s 

rad/a 

rad/a 

m 

kg/m 

A-s/V 

A/V 

V/m 

V-s/A 

W/A 

V/A 

W/A 

N-tn 

|/K 

kg-m/s 

(cyclej/s 

im/m 

cd/m 

cd-sr 

A/m 

V-s 

Wb/m 

i'» 

N/m 

A-s 

N-tn 

W/ar 

J/kg-K 

N/m 

W/m-K 

m/s 

Pa-s 

m/s 

W/A 

m 

(wave)/m 

N-m 


SI  PREFIXES: 


Multiplication  Factors  Prefix 


1 000  000  000  000  = 

10'1 

tnra 

1 000  000  000  = 

10’ 

gig* 

1 000  000  = 

10* 

mega 

1 000  = 

101 

kilo 

100  = 

101 

hecto* 

10  = 

10' 

deka* 

0.1  = 

10-' 

decl* 

0.01  - 

10-» 

centl* 

0.001  = 

10-* 

mllll 

0.000  001  = 

10*  * 

micro 

0.000  000  001  = 

10-* 

nano 

0.000  000  000  001  •» 

10-'1 

uico 

0.000  000  000  Q00  001  » 

10"'* 

frnnto 

0.000  000  000  000  000  001  ~ 

10-'* 

atto 

* To  bo  avoided  whore  possible 

- M — B — 8 — - ■ I ----- -w  I 


SI  Symtxil 

T 

C 

M 

k 

h 

da 

d 

c 

m 

n 

r 


MISSION 

of 

Rome  Air  Development  Center 


RADC  plans  and  conducts  research,  exploratory  and  advanced 
development  programs  In  command,  control,  and  communications 
(C3)  activities , and  in  the  C3  areas  of  information  sciences 
and  intelligence.  The  principal  technical  mission  areas 
are  communications,  electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling , information  system  technology , 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability , maintainability  and 
compatibility . 


